store: Support importing images without /ostree#887
Conversation
A sticking point keeping ostree in the picture here for containers was SELinux handling. When we started this effort I'd feared rewriting. But recently we changed things such that we label derived images using the policy from the final root. This is a relatively small change in code size and complexity, that allows us to import images that don't have "ostree stuff" in them at all, i.e. there's no `/ostree/repo/objects`. The advantage here is that this significantly simplifies constructing base images. The main disadvantage today for people who build images this way is that we end up re-labeling and re-checksumming all objects. But, the real fix for that in the future will be for us to rework things such that we support `security.selinux` for example as native xattrs in the tar stream. Signed-off-by: Colin Walters <walters@verbum.org>
|
This was migrated from ostreedev/ostree-rs-ext#674 btw. |
composefs is something we generate client side; it's not directly related except in that today one needs to explicitly turn on ostree-composefs in the container image's content.
See https://gitlab.com/fedora/bootc/tracker/-/issues/32#note_2201993683 - so yes, one could derive from ubi too. |
|
I was asked about this PR recently, and just to clarify: I'd consider this PR "supported" in the sense that we will absolutely fix any bugs that arise, and we do have some tests, but it's just less battle tested than the previous path. At some point we will probably try to change fedora-bootc to do this by default, but we have to be really cautious because we need to support people upgrading from old systems where the bootc won't support this. So the overall goal is basically:
(This issue also touches on #640 in that in theory it could help us get out of these bootstrap requirements; the bootc-in-target could handle any fixups) |
|
To extend the previous comment, we now test the "no ostree in container" flow pretty well too in various places, it's the default output of the https://docs.fedoraproject.org/en-US/bootc/building-custom-base/ flow. |
2 participants
A sticking point keeping ostree in the picture here for containers was SELinux handling. When we started this effort I'd feared rewriting.
But recently we changed things such that we label derived images using the policy from the final root.
This is a relatively small change in code size and complexity, that allows us to import images that don't have "ostree stuff" in them at all, i.e. there's no
/ostree/repo/objects.The advantage here is that this significantly simplifies constructing base images.
The main disadvantage today for people who build images this way is that we end up re-labeling and re-checksumming all objects.
But, the real fix for that in the future will be for us to rework things such that we support
security.selinuxfor example as native xattrs in the tar stream.